The requirement for more safety, efficiency, comfort as well as improved environmental compatibility permits the mechatronic in the motor vehicle to become an ever more significant and competition determining factor. Economical vehicle developments and the mastery of complex system structures in ever shorter production cycles compel universal computer-supported development processes which are automated as far as possible. In the analysis phase, modular expandable architectures for “function”, “safety” and “electronics” can be specified on the basis of agreed to formal structuring rules and modeling rules of the ordering concept Cartronic, which is neutral with respect to automobile manufacturers and suppliers.
The demand for more safety, efficiency, comfort and improved environmental compatibility allows the mechatronic in the vehicle to become an ever more significant and competition determining factor in the conversion of technology from mechanics via electronics to information technology. In the continuously increasing complexity of the systems and production cycles which simultaneously become ever shorter, the cost and development complexity remains controllable only with the use of a universal computer-supported and substantially parallallelized work and development process, which is automated as far as possible.
A starting point for solving the partially diverging requirements is the networking of the individual systems, which up to now have worked substantially independently of each other, to a vehicle-wide integrated system and the logic combination of system components to functional units having standardized interfaces. The system network offers the possibility of a cooperation and multiple use of sensor means as well as actuator means and therefore a utilization of emerging functions.
The networking furthermore makes possible a conversion of pure function-oriented realizations to configurations wherein the application functions can be imaged to networked control apparatus. Furthermore, in partial system faults, dynamic shifting of functions to other systems can be supported.
Starting from logic function units having standardized interfaces, it likewise becomes possible to network functions of different origin and of various automobile manufacturers and suppliers to each other. A function supplier must then guarantee that the function maintains the required specification even for distribution to several network control apparatus.
The development of complex networked systems has as a precondition a systematic process having recursive phases and the use of computer-supported tools. In this process, the automobile manufacturer as well as the supplier can formulate all the requirements and peripheral conditions for the function to be developed and analyze the many interactions with other functions and the ambient in all application situations and fault situations and can evaluate the function with respect to its effect on the entire network. For the development of complex networked systems, the V-model has become established as the model of approach also in the automobile industry. The V-model provides that all activities and sequences for function development can be arranged in eleven phases (FIG. 1).
The V-model describes a procedure wherein the specification and development processes are characterized by detailing and refinement and can be viewed as a top-down approach. In contrast, the verification and validation phases are bottom-up approaches. Essential requirements and preconditions for quality certification are detailed documentation papers for each individual phase.
The order concept “Cartronic” (see T. Bertram, R. Bitzer, R. Mayer and A. Volkart, 1998, Cartronic—An Open Architecture for Networking the Control Systems of an Automobile, Detroit/Mich., USA, SAE 98200, 1–9) was developed in order to satisfy the requirements for an economic vehicle development, the mastery of complex system structures and an adequate documentation.
In a first phase of the process chain, the analysis, the ordering concept, which is developed on the object-based basic idea, makes possible the logic combination of system components in functional units having standardized logic interfaces. The description of the networking of individual systems of a motor vehicle (which systems, up to now, work substantially independently of each other) therefore defines a (meta)-model for a modular expandable function architecture, safety architecture and electronic architecture. An essential advantage of this automobile-manufacturer neutral and supplier-neutral specification possibility is that, after a short work-in time, the logic description of the requirements is understandable to all participants in the development process already at a very early development time point.
As essential documentation elements, graphic-based models support, during all development phases, a communication between all persons, who participate in the development, as well as the maintenance and further development after completing the development. Supplementary to classical software engineering, the following groups of persons are to be supported for mechatronic system development in the motor vehicle industry: vehicle manufacturers as users/customers; as well as interested persons who require information as to the functions of the system; engineers in the area of mechanical engineering and electrical engineering; as well as computer personnel as developers of the mechatronic components on the manufacturer and supplier end; as well as those persons who modify or expand these components after a completed development and who therefore require understanding of the entire system or its parts; managers on the developmental and customer end who need organizational and economic details for project control, computation of costs and information as to future projects and developments; and, the vehicle drivers as special end users who must be made familiar with selected functions of the system.
An essential step at the end of the analysis phase and at the beginning of the design phase is the mapping of specification models, developed in Cartronic, into an information-technical draft for the software development. This mapping contributes to the increase of the information density and the expansion of the semantic content of built-up Cartronic models; defines component systems in a total system architecture; increases the transparency of the total system with the target direction of the implementation thereof; and, provides essential bases for a distributed development and testability of mechatronic systems.
In the following, a mapping of specification models, developed in CARTRONIC®, into a standardized object-oriented illustration is described with the background of a support as wide as possible via commercially available software development tools. A suitable notation or symbol which is required therefor is the object-oriented language standard of the unified modeling language (UML). The language standard is internationally standardized by the object management group (OMG).
In the following, a summarizing description of the structural elements and formal structuring rules as well as modeling rules in accordance with CARTRONIC® is given for function architectures. Furthermore, a function architecture of the entire vehicle with a detailing for the component “drive” is presented on a high abstraction plane. Proceeding from this, the description of theoretical bases of modeling first follows before the applied elements of the object-oriented notation with UML is discussed in the further course of this section. The procedure for the available model in accordance with Cartronic® is shown with respect to an example.
An example of a system network, which exists already in present day vehicles, is the drive slip control. This is only made possible by the communication of the control apparatus for the drive slip control with the control apparatus for the motor management for the control of the drive torque.
CARTRONIC® is an ordering concept for all control systems (open loop and/or closed loop) of a vehicle. The concept includes modular expandable architectures for “function”, “safety” and “electronics” on the basis of agreed to formal structuring rules and modeling rules.
Architecture is here understood to mean the structuring system (rules) as well as their conversion into a specific structure. The function architecture includes all control (open-loop and/or closed loop) tasks which occur in the vehicle. The tasks of the system network are assigned to logic components and the interfaces of the components and their interaction are determined. The safety architecture expands the function architecture by elements which guarantee a reliable operation of the system network. Finally, a system is given for the electronics as to how the system network is to be realized with requirement optimized hardware topology.
The elements of the architecture are components and communications relationships, on the one hand, and structuring and modeling rules, on the other hand. In the context of structuring, a system is considered as a combination of components to form a whole which interact with each other via communication relationships. The term “component” does not perforce mean a physical unit in the sense of a part but is understood to be a function unit. In the ordering concept, three different types of components are distinguished:                components with mostly coordinating and distributing tasks;        components having primarily operative and executing tasks;        components which exclusively generate and make available information.        
In the communication relationships, one distinguishes between a task (with feedback), an inquiry (with reference) and a request. The task is characterized by the duty of execution and, for the case where the task is not fulfilled, the task receiver has to provide a feedback to the task giver, which describes the reason for non-execution. The inquiry function serves to obtain information for the execution of a task. In the case that a component cannot make available the requested information, the component gives a hint to the inquiring component. A request describes a “wish” that a function is executed by another component. However, the duty of fulfilling is not coupled to the request, which is considered, for example, with competing requests. The following table summarizes the structural elements.
STRUCTURALELEMENTSHORT DESCRIPTIONComponentLogic function unitEnvelopeFrom a detailed component, there remainsan envelope which transmits thecommunications to the subcomponents aswell as expresses an “is part of”relationship (viewed from the outside tothe inside)SystemA system comprises several components and(sub) systems (viewed from the inside tothe outside)Order (withOrder to act with duty to execute afeedback)functionInquiry (with hint)Determination of an informationRequest“Wish” for executing a functionRulesRules for:communication relationshipsmodeling patterns
The structuring rules describe permitted communication relationships within the architecture of the entire vehicle. One distinguishes structuring rules which control the communications relationships on the same abstraction plane and into higher and lower planes while considering indicated peripheral conditions. Further, the structuring rules clarify the transmission of communication relationships from one system into another system into its detailing.
The modeling rules contain patterns which combine components and communication relationships for the solution of special tasks which come up often. These patterns, for example, an energy management, can then be used again at different locations within the structure of the vehicle.
A structure, which is developed in accordance with the structuring and modeling rules, is characterized by the following features:                agreed to uniform structuring and modeling rules on all abstraction planes;        hierarchical task flows;        high self responsibility of individual components;        operator-controlled elements, sensors and estimators are equal information generators; and,        casing, which makes each component as visible for the remaining components as necessary and as invisible as possible.        
FIG. 2 presents, by way of example, the architectural features and the permitted communications relationships. These are (for simplicity's sake, only the following are referred to: order, inquiry and request, however, what is meant is the relationship which each of these makes possible):                the order torque_ga (make torque available at transmission output) which is transmitted by the envelope “drive” to the input component “drive coordinator” which, at the same time, is also “coordinator”;        the orders: torque_ga (make torque available at motor output), establish force connection and set gear (set one of the gears) from drive coordinator to motor, converter and transmission;        the request !rGear (reverse gear) from the transmission operating field to the drive coordinator;        the inquiries ?state and ?airpressure (of the ambient) to transmission and ambient; as well as        the inquiries ?gear (reverse gear or not) and ?rpm to the envelope “drive”, which the envelope transmits further to the appropriate components “motor” and “transmission”.        
In the classical software life cycle, the following phases, which have to be run through rigidly sequentially, are distinguished: problem analysis, systems specification, draft, implementation with component test, total test and introduction as well as operation and maintenance of a software system. In practice, such a rigid sequential development process is an idealization which cannot be maintained. Theoretically clearly defined points overlap or are, under circumstances, advanced to different extents, at the same time, the know-how moves on simultaneously on behalf of all participants in the development process with the system development. An object-oriented procedure makes possible a phase overlapping procedure with, ab initio, high reusability of already developed or available components and concepts. This is significantly facilitated with the use of a computer-supported graphic symbol. The various method procedures, which are used in the object-oriented software development, contain a graphic symbol developed specifically for the particular method. The UML proceeded from the three methods mostly used in the industrial software development: the Booch method named for Grady Booch; the object modeling technique (OMT) developed under James Rumbaugh; and, the object-oriented software engineering (OOSE) developed under Ivar Jacobson. The UML defines no further new universal methods, rather, a meta model for the construction of models for different views (FIG. 3). It defines a graphic and supplementing tabular and textual notation or symbol having uniform syntax and clearly defined semantics.
Developed UML models are clearly interpretable by all persons participating in the development process and often have the following significant advantages:                the use of an international standard;        a tool supported procedure which is as independent as possible from the manufacturer;        a softening of the rigid maintenance of the classical sequential sequences of analysis phase and design phase in the software development without abandoning the software life cycle model as a basis of an engineer-like top-down procedure;        as far as possible, independence from the used program language on the logic plane;        the maintenance of the consistency between analysis, design draft and implementation; and,        the possibility of a simultaneous bottom-up reverse-engineering procedure.        
In the analysis phase, CARTRONIC® models arise as a predetermined structured specification of what the mechatronic system is intended to do. These models define an object-based abstraction of the functional logical concepts from the vehicle system structures. With a suitable mapping into a substantially more powerful UML model, the change from the analysis phase into the design phase and the developmental phase takes place. Here, the foundations for the total architecture of the software system are laid and component systems for the reduction or mastery of the complexity are defined and clean interfaces between these are specified. The addition of more and more details leads, in the advancing development process, in the direction of implementation. The target of the design or development phase lies in the: fixing of the system components, the assembly of these components and interfaces with the definition of the logic data model, which form the basis, including the data and algorithmic structures as well as the validation thereof. Complexity is to be mastered via abstraction. The simplicity as well as the ability to have an overview of the entirety must be guaranteed (structuring in the larger sense). In later steps, the structuring refers likewise to the selection of appropriate program components in the algorithmic formulation with the objective of optimizing the required power characteristics of the system (structuring in the smaller sense). The object of the implementation phase lies in the conversion of the logic data model, the system architecture and algorithms into a translatable program code for the individual control apparatus and the communications network in the motor vehicle.